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ABSTRACr  i  8  Viw 

This  paper  presents  a  view  of  research  dirccuons  relevant  to  producing  rcUahk  and  usclul  Ck  \ 
software  systems  Appropriate  rcscareh  goals  arc  Kkrntilied  lor  achieving  imptosemenis  itt  ' 
stsftware  quality  via  lomiali/alion  and  computer  aid  for  st>iiwarc  an.ijvsi\  svinhcMs  atkl 
cenification  tasks  at  all  smges  of  sof!w  ;irc  dcvclopineni  and  cvoluiioti 


1.  Introduction 

Systematically  producing  and  adapting  reliable  software  that  meets  the  needs  of 
its  cliencs  is  a  dominant  software  engincenng  problem  in  the  Reliability  of 

software  products  is  a  concern  particularly  fur  systems  whose  malfunciiun  may  result 
in  lost  lives,  injuries,  or  financial  losses.  It  is  practically  impossible  to  produce  ernsr- 
free  software  systems  that  solve  real  (complex)  problems  by  pumly  manual  develop¬ 
ment  methods  becau.se  human  error  rales  arc  too  high.  Sound  automatable  methods  lor 
software  analysis,  synthesis  and  ccriiticaiion  arc  needed  U)  bndge  this  gap  For  practi¬ 
cal  impact,  these  methods  must  fit  together  to  cover  the  eniirc  .scrftwarc  development 
and  evolution  process.  Software  ovoluiitm  {.sometimes  called  maintenance)  is  a  major 
concern  in  this  context  bccau.se  errors  are  often  introduced  as  a  .sy.stem  is  modified, 
and  evolution  typically  accounts  for  more  than  half  of  the  effort  of  developing  and 
supporting  a  software  system. 

Reliability  concerns  indicate  that  we  need  automated  assistance  in  all  stages  of 
software  development,  but  complete  automation  of  software  development  and  evolution 
is  not  feasible  in  the  near  future.  Some  realistic  research  goals  in  this  situation 
include: 

(1)  Formulating  a  consistent  set  of  accurate  mathematical  models  fur  a  set  of  .sub¬ 
problems  covering  the  software  development  process.  This  is  needed  to  enable 
integration  of  the  methods  and  tools  for  solving  problems  related  to  different 
aspects  of  software  development. 

(2)  Developing  and  certifying  the  correctness  of  completely  automated  synthesis 
methods  for  the  tractable  subproblcms.  In  cases  where  this  is  possible,  this 
approach  provides  both  reliability  and  productivity  gains. 

(3)  Developing  interactive  synthesis  methods  that  guarantee  absence  of  errors  for  less 
tractable  subproblems.  This  approach  combines  the  benefits  of  human  creativity 
with  the  accuracy  provided  by  computer  application  of  sound  formal  methods. 

(4)  Improving  analysis  and  certification  methods  capable  of  detecting  and  diagnosing 
errors  for  subproblems  that  cannot  be  covered  by  error  prevention  techniques.  If 
aspects  of  the  process  must  remain  manual,  then  automated  assistance  for  locating 
and  removing  errors  and  for  certifying  that  no  errors  are  left  are  needed  for  those 
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aspects. 

Most  of  the  pa.st  work  on  improvmi;  sofiw'are  reliability  has  fallowed  the  las! 
approach.  Thi.s  direciion  has  enabled  researchers  to  prtivide  some  useful  tools  witluiu! 
waiting  for  full  understanding  of  all  of  the  problems  invtilved.  This  direcuon  is  also 
the  least  de.sirable  one  for  the  future  because  the  search  for  errors  is  of  ten  very  labor 
intensive  and  because'  it  is  difficult  to  predict  how  many  iterations  will  be  needed  to 
eliminate  all  of  the  errors.  Thus  error  detection  work  is  most  reasonable  for  dui.w 
aspects  of  software  development  for  which  error  prevention  techniques  are  niii  feasible 

2.  Assessing  the  State  of  the  Art 

Past  approaches  have  considered  isolated  subprubiems  of  the  real  sttiiwarc  reha 
bility  problem,  mostly  at  the  code  level. 

Work  on  software  testing  has  produced  a  few  solid  results  in  addition  to  many 
heuristics  who.se  cffeciivcnc.s.s  is  difficult  to  evaluate.  Successful  execution  of  test  sei.s 
constructed  by  random  sampling  from  a  probability  distribution  can  provide  kuwer 
bounds  on  the  mean  number  of  executions  between  failures  if  actual  input  value 
correspond  to  the  given  probability  distribution  {6].  Thi.s  kind  of  siaiisiical  rchabihiy 
assurance  is  sufficient  in  cases  where  input  distributions  arc  predictable  and  non  /ero 
failure  rates  can  be  tolerated.  Statistical  as.suranccs  are  not  sufficient  for  critical  appli¬ 
cations  where  even  one  failure  is  unacceptable.  SiaUsiicai  reiiahiiity  measures  can  alvt 
be  misleading  if  real  input  distributions  arc  unstable  or  unknown,  because  there  exist 
input  distributions  with  high  failure  rates  for  any  deterministic  program  that  is  not 
completely  error- free. 

For  some  specialized  clas.ses  of  programs,  there  exist  methods  for  constructing  a 
finite  -SCI  of  test  cases  whose  successful  execution  can  esiahiish  correcine,s.s  of  the  pro¬ 
gram  for  all  possible  inputs  (4,6).  Thi.s  is  not  possible  in  the  general  case:  testing  can 
show  the  presence  of  software  errors  hut  it  cannot  certify  their  ah.scncc  for  uncon¬ 
strained  programs. 

Work  on  program  verification  has  sought  to  construct  and  mechanically  check 
mathematical  proofs  that  given  programs  meet  given  specifications  for  ail  possibic 
inputs.  Methods  for  doing  this  exist,  but  this  technology  is  not  yet  mature  for  practical 
applications,  particularly  with  respect  to  tool  support  and  range  of  applicability  of  the 
formal  models.  Weaknc,s.se.s  of  current  technology  include  the  following. 

(1)  Proving  that  a  program  satisfies  a  given  specification  is  useless  x^ithoui  some 
assurance  that  the  specification  is  valid,  i.e.  that  it  accurately  repmsenLs  the  needs 
of  the  users  of  the  program.  Validation  of  specifications  is  a  major  task  and  sys¬ 
tematic  methods  for  doing  this  are  not  well  developed. 

(2)  It  is  impossible  to  prove  that  an  incorrect  program  satisfies  its  specification.  Past 
studies  indicate  that  it  takes  much  more  effort  to  construct  code  that  fully  meets  a 
specification  than  it  docs  to  mathematically  verify  a  correct  program  (5). 

(3)  Current  systems  require  considerable  human  assistance,  and  the  mathematical 
skills  required  to  use  thc.se  systems  are  beyond  the  abilities  of  many  practicing 
software  developers. 
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3.  Future  Opportunities 

More  recently  proposed  approaches  focus  on  error  prevention  rather  than  error 
detection.  Error  prevention  is  possible  both  in  cases  where  a  software  development 
task  can  be  completely  automated,  and  in  cases  where  an  automated  tool  reaJixe.s  all  (»f 
the  designer’s  decision’s  in  constrained  ways  that  do  not  allow  the  designer  to  make  a 
mistake,  or  that  eliminate  some  kinds  of  mistakes.  Some  examples  arc  meaning* 
preserving  software  transformations,  which  prevent  divergences  between  specifications 
and  the  code  [2).  and  syntax-directed  editors,  w'hich  prevent  the  creation  of  programs 
that  do  not  conform  to  the  syntax  of  the  programming  languages 

It  is  commonly  believed  that  error  p.''eveniion  is  more  difficult  than  error  detec¬ 
tion.  but  this  is  not  always  the  case.  For  example,  checking  whether  an  c^uaciona! 
.s;)€cification  for  an  abstract  data  type  is  consistent  and  complete  is  an  undccidable 
problem.  Nevertheless,  there  exists  an  error  prevention  technique  that  guarantees  that 
ever>'  specification  that  can  be  generated  according  to  the  rules  is  complete  and  con¬ 
sistent.  These  rules  are  simple  enough  to  be  applied  and  checked  by  a  text  editor,  and 
they  are  sufficiently  loo.se  to  accommodate  the  styles  of  specification  that  normally 
occur  in  practice  [1]. 

Software  development  deals  with  information  of  many  different  kind.s.  at  different 
levels  of  abstraction.  We  summarize  .some  of  the  types  of  software  analysis,  synthesis 
and  certification  problems  that  should  be  investigated  for  .several  levels  of  .software 
representations  in  Fig.  I. 

3.1.  Requirements  Level 

The  requirements  level  eslabli.shes  the  goals  for  a  proposed  .system  and  formulates 
models  of  the  problem  and  the  expected  environment  of  the  propo.scd  system. 

An  important  aspect  of  requirements  analysis  is  achieving  and  maintaining  con¬ 
sistency  as  the  analysis  di.scover  and  record  the  requirements.  A  promising  approach 
to  this  problem  is  providing  automated  support  for  calculating  and  maintaining  derived 
properties  and  consequences  of  the  requirements,  and  for  tracing  dependencie,s  to 
determine  the  causes  of  conflicts  and  inconsistencies.  Better  algorithms  for  this  pro¬ 
cess  and  primitives  suitable  for  expressing  and  effectively  maintaining  dependencies  in 
software  requirements  should  be  investigated. 

Another  aspect  of  requirements  analysis  is  modeling  the  environment  of  a  pro¬ 
posed  system.  Especially  for  embedded  software  systems,  an  accurate  formal  charac¬ 
terization  of  the  system  to  be  controlled  is  essential  for  assessing  the  effectiveness  of 
the  control  software.  The  environment  of  such  a  system  must  often  be  simulated  or 
otherwise  formally  analyzed  to  enable  safe  and  meaningful  testing  or  analysis  of  the 
embedded  software  system.  Systematic  methods  for  validating  and  testing  the  formal 
models  of  the  environment  against  the  properties  of  the  actual  physical  sy.stem.s  they 
represent  are  needed.  Both  analytical  and  experimental  methods  should  be  explored  to 
establish  that  the  formal  environment  models  used  in  other  software  analysis  and  test¬ 
ing  activities  are  adequate  representations  of  reality. 

Many  critical  software  systems  are  embedded  systems,  which  means  diat  the 
software  is  part  of  a  larger  system.  Thus  an  essential  part  of  checking  the  adequacy  of 
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Level 


Type  of  Analysis/Synihesis 


Requirements 


Specification 


Design 


Coding 


consistency:  truth  maintenance 

model  validation:  simulation  and  pioof 

subgoal  verification;  prototyping  and  protif 

adequacy;  prototyping,  operational  scenarios 
consistency:  type  and  domain  checking 
safety:  proofs 

validation:  paraphrasing,  views,  simplification 

verification:  proof  of  decomposition 
liveness:  deadiiK'k  and  starvation  checking 
robustness:  impact  of  degraded  hardware 
design  for  testing:  control  and  observation 
performance:  complexity  analysis 
feasibility:  .satisfiability  proofs 

synthesis:  meaning-preserving  transformations 
performance:  time  and  space  analysis 
liveness;  proof  of  (clean)  termination 
real-time:  analysis  of  .scheduling  methods 
generic  units:  analysis  of  component  families 
error  detection:  complete  test  sets 
error  location:  weake.st  preconditions 


Evolution  change  impact:  symbolic  differences 

restructuiing;  meaning-pre.serving  transformations 
error  prevention;  change  merging 

Fig.  1  Types  of  Software  Analy»s  and  Testing 


the  requirements  for  the  software  is  checking  that  any  system  meeting  the  requirements 
will  be  sufficient  to  meet  the  requirements  for  the  larger  system  in  its  intended  opera¬ 
tional  context.  Hard  real-time  constraints  in  an  embedded  system  are  often  motivated 
by  the  requirement  to  control  the  larger  system  to  ensure  it  remains  within  a  given 
range  of  operating  states.  For  example,  the  cycle  rate  of  an  auto-pilot  must  be 
sufficiently  high  to  ensure  that  the  airplane  remains  within  a  given  radius  of  its 
planned  position  at  all  times.  At  the  current  time,  lower  level  requirements  are  usually 
formulated  based  on  past  experience  and  informal  guidelines  rather  than  on  systematic 
derivations  or  verification  procedures  with  respect  to  the  higher  level  requirements. 
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Both  formal  and  experimental  methods  for  systematically  esiahlis'ang  such  properties 
are  needed.  Required  supporting  technology  for  this  process  include.s  computer  aided 
construction  of  prototypes  (7]. 

3.2.  Specification  Level 

The  specification  level  is  concerned  with  defining  the  interface  of  a  propo.sed  sys¬ 
tem,  both  at  the  functional  and  the  command  representation  levels. 

The  primary  measure  of  the  adequacy  of  a  specified  interface  is  whether  it  will 
meet  the  needs  of  the  user.  This  question  is  best  addressed  by  experimental  rather 
than  analytical  techniques  because  it  addresses  the  problem  ol  checking  the  correspon¬ 
dence  between  a  formalized  specification  and  the  actual  and  informal  needs  of  the 
users.  One  way  of  approaching  this  problem  is  via  prototyping  and  operational 
scenarios.  Operational  scenarios  are  common  tasks  in  the  customer’s  problem  domain, 
expressed  in  the  user’s  terms.  Such  scenarios  serve  as  le.st  cases  for  the  specifications, 
whose  purpose  is  to  determine  whether  a  proposed  interface  is  adequate  for  carrying 
out  all  of  the  tasks  the  users  will  have  to  perform.  Such  a  test  pas.ws  if  the  facilities 
provided  by  the  propo.sed  syjuem  interface  can  be  combined  to  carry  out  the  tasks  in 
the  operational  scenario,  and  provide  a  systematic  means  for  exercising  a  protoij  pc  in 
a  demonstration  to  the  users.  Systematic  methods  for  deriving  .sets  of  scenarios  from  a 
requirements  document,  coverage  criteria,  and  experimental  evaluation  of  the  effects  of 
such  coverage  criteria  on  change  requests  to  the  affected  interfaces  during  sy,siem 
maintenance  should  bo  investigated. 

A  related  concern  is  validating  a  formal  specification,  to  ensure  that  it  correctly 
captures  the  intentions  of  the  users.  While  this  is  an  informal  process,  it  can  be  aided 
by  formalized  and  automatable  procedures.  Symbolic  execution  and  operational 
scenarios  can  be  applied  to  this  problem.  Proof  techniques  can  aLso  be  used  in  this 
way  {8],  by  obtaining  a  list  of  expected  system  properties  and  then  proving  that  the 
formal  specification  has  those  properties.  Other  relevant  processes  involved  are  para¬ 
phrasing,  projection,  and  simplification.  Paraphrasing  is  the  process  of  transforming  a 
formal  specification  into  a  form  that  a  user  can  understand,  while  preserving  iLs  mean¬ 
ing.  Projection  is  the  process  of  extracting  the  parts  of  a  specification  relevant  to  a 
particular  user  or  task,  while  hiding  other  details.  Simplification  is  the  process  of 
transforming  a  formal  specification  into  a  simpler  form  with  an  equivalent  meaning. 
These  three  processes  can  be  combined  to  help  users  selectively  review  formal 
specifications  using  representations  they  can  understand.  The  research  questions  in  this 
area  concern  certifying  the  transformations  to  ensure  they  pre.serve  the  meaning  of  the 
specification  and  experimentally  evaluating  the  effectiveness  of  different  repre,scnia- 
tions  for  communicating  with  untrained  users. 

Consistency  of  a  specification  is  another  common  concern,  especially  for  large 
and  complex  systems.  Since  consistency  is  a  property  of  a  formal  document,  it  can  be 
addressed  by  analytical  techniques.  Some  aspects  of  consistency  checking  that  need 
further  development  are  type  and  domain  consistency  checking.  Type  checking  at  the 
specification  level  is  more  difficult  than  the  corresponding  problem  at  the  code  level 
because  types  can  have  subtypes  defined  by  semantic  considerations.  Domain 
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checking  is  the  process  of  ensuring  that  partial  functions  or  predicates  are  used  only 
within  their  domain  of  definition,  and  that  partially  defined  generic  units  are  instan¬ 
tiated  only  with  actual  parameters  in  their  respective  domains  of  definition  Logical 
inference  capabilities  are  necessary  for  both  of  these  kinds  of  specification  analysis 

Another  concern  with  formal  specifications  is  checking  sateiy  properties.  Ft'r 
example,  past  research  projects  have  been  concerned  with  whether  a  proposed  operai 
ing  systems  kernel  satisfied  certain  security  properties,  such  as  the  impossibility  ol 
transmitting  classified  information  from  a  process  with  a  high  security  cla.ssificaiion  to 
an  unauthorized  process.  The  goals  of  safety  analy.sis  procedures  are  to  ideniily  cases 
where  the  specifications  allow  behaviors  violating  the  safety  properties,  or  to  certify 
that  no  such  cases  exist  Systematic  procedures  for  this  process  are  needed  because 
the  connection  between  a  formal  specification  and  a  safety  property  can  he  quite 
indirect  and  can  require  extensive  rea-soning  and  analysis  to  establish. 

3.3.  Design  Level 

The  design  level  is  concerned  with  the  decomposition  of  a  problem  into  a 
hierarchical  structure  of  independent  modules.  .Such  a  decomposition  consists  of  inter¬ 
connection  information  and  formal  specifications  for  the  components 

The  primary  reliability  property  of  a  decomposition  structure  is  whether  it  will 
correctly  realize  the  specification  at  the  next  higher  level.  This  problem  is  subject  to 
mathematical  proof  techniques.  The  problem  is  easier  to  solve  than  the  general  proof 
of  correctness  problem  at  the  code  level  becau.se  the  module  interconnection  language 
is  can  be  considerably  simpler  than  a  programming  language.  Most  of  the  analysis  can 
be  carried  out  at  the  specification  level,  since  the  problem  is  to  check  whether  a  given 
combination  of  specified  components  will  satisfy  the  required  properties  of  the  compo¬ 
site.  Research  questions  in  this  area  involve  the  be.st  choice  of  interconnection  primi¬ 
tives  to  support  effective  and  efficient  inference  proccu’ires,  and  formal  characteriza¬ 
tions  of  interfaces  and  resource  models  sufficient  to  ensure  correctne.ss  of  decomposi¬ 
tions  in  the  presence  of  distributed  processing  and  hard  real-time  con.strainis. 

Another  type  of  property  of  interest  for  parallel  and  distributed  systems  is  livo- 
ness.  Techniques  for  checking  for  potential  deadlock  or  starvation  conditions  in  such  a 
design  are  desired.  Deadlock  detection  appears  to  be  decidable  for  asynchronous 
models  and  undecidable  for  synchronous  ones.  Some  research  problems  in  this  area 
include  developing  solutioas  to  the  problem  in  the  error  prevention  style,  and  develop¬ 
ing  better  symbolic  techniques  for  deadlock  detection  and  diagnosis.  The  problem 
with  past  finite-state  techniques  for  deadlock  detection  is  that  practical  applications 
often  have  state  spaces  that  are  much  to  large  for  enumeration  techniques  to  be  applied 
in  practice.  Formal  approaches  that  can  avoid  state  enumeration  via  induction  and  log¬ 
ical  reasoning  should  be  developed  further. 

An  important  class  of  analysis  involves  the  effects  of  degraded  hardware  on  the 
properties  of  a  design,  relative  to  a  mapping  of  software  components  to  hardware  com¬ 
ponents.  This  kind  of  analysis  is  essential  for  achieving  reliable  fault  tolerant  systems, 
especially  those  with  distributed  implementation.s.  In  addition  to  certifying  that  pro¬ 
posed  configurations  realize  given  degrees  of  fault  tolerance,  automatic  derivation  of 
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the  implied  constraints  on  allocation  of  software  functions  to  hardware  units  is  desir¬ 
able. 

Evaluation  of  a  design  for  time  and  space  performance  is  another  kind  of 
software  analysis  that  has  potential  importance.  Automated  support  for  classicai  com¬ 
plexity  analysis  is  needed,  along  with  estimates  for  the  ranges  of  input  si/a.\s  and  con¬ 
stant  factors  determined  by  classes  of  algorithms, 

A  final  consideration  is  satisfiability.  The  satisfiability  of  a  specification  can  be 
established  if  an  implementation  can  be  produced  and  certified  to  he  correct.  How¬ 
ever,  it  would  be  useful  to  determine  whether  it  is  possible  to  satisfy  a  given 
specification  before  the  implementation  is  attempted,  and  in  cases  where  it  is  not,  to 
characterize  the  set  of  inputs  for  which  the  specification  i-s  impo.ssihle  to  meet. 
Analytical  techniques  for  constructing  weakest  infeasible  preconditions  characterizing 
this  set  of  inputs  should  be  explored.  Since  it  is  possible  to  derive  programs  from 
sufficiently  constructive  proofs  of  the  satisfiability  of  a  specification,  further  research 
along  these  lines  has  good  potential  for  producing  a  practical  impact. 

3.4.  Code  Level 

The  best  way  to  achieve  quality  is  to  sy.stematically  prevent  errors.  Automatable 
methods  for  synthesis  of  efficient  code  from  formal  specifications  via  meaning¬ 
preserving  transformations  should  be  investigated.  Of  particular  interest  are  system.s 
that  can  choose  transformations  without  explicit  human  guidance,  or  with  guidance 
from  general  declarative  advice  that  can  be  formulated  without  explicit  reference  to  the 
details  of  the  current  slate  of  the  derivation  and  does  not  require  explicit  human 
interaction  during  the  derivation  process. 

Accurate  performance  analysis  requires  detailed  code  and  knowledge  about  pro¬ 
perties  of  a  particular  compiler  and  target  machine.  Generic  table  driven  methods  for 
performing  such  analysis,  and  for  relating  design-level  properties  of  abstract  algorithms 
to  detailed  properties  of  actual  machine-level  implementations  and  compiler  optimiza¬ 
tions  is  needed  to  accurately  certify  correctness  of  programs  with  hard  real-time  and 
real-space  constraints.  Research  problems  in  this  area  include  formal  modeling  of 
implementation-specific  properties  and  constraints  in  ways  that  can  be  combined  with 
implementation-independent  analyses  of  abstract  programs. 

Another  problem  is  certification  of  clean  termination.  This  problem  gains  new 
dimensions  in  parallel  and  distributed  systems,  where  termination  can  be  influenced  by 
scheduling  properties  and  hardware  failures.  Research  questions  include  models  and 
techniques  for  analyzing  programs  in  these  domains. 

Analysis  of  real-time  systems  includes  analysis  of  scheduling  methods  to  deter¬ 
mine  whether  a  proposed  scheduling  discipline  will  meet  specified  deadlines  under  all 
possible  operating  conditions.  Research  questions  in  this  area  have  flexible  scheduling 
methods,  the  effects  of  shared  resources,  overload  resolution  policies,  and  remote  com¬ 
munications  as  major  concerns. 

The  problem  of  certifying  generic  code  units  or  families  of  related  programs  gen¬ 
erated  by  meta-programming  schemes  is  a  major  concern  in  systems  for  managing 
reusable  software.  A  software  component  is  most  effectively  re-used  if  it  is  flexible 
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and  can  be  adapted  to  many  needs.  Such  a  component  often  corresponds  to  a  family 
of  related  program  units  with  an  unbounded  number  of  elements.  The  problems  of 
testing  and  analyzing  the  reliability  of  such  program  families  is  an  important  reseaich 
question. 

Classical  testing  approaches  need  more  foundational  work  on  the  construction  of 
complete  test  sets.  A  complete  test  set  is  a  set  of  test  cases  which  is  guaranteed  to 
detect  any  error  in  a  particular  well-defined  class  of  eirors.  More  work  is  needed  on 
the  construction  of  finite  complete  test  sets,  an  on  characterizing  the  set  of  faults 
whose  absence  is  guaranteed  by  successful  execution  of  the  test  set.  Such  work  should 
include  automated  techniques  for  constructing  the  required  test  oracles  from  the  formal 
specifications  of  the  code  to  be  tested.  A  weakness  of  statistical  approache.s  to  testing 
is  the  size  of  the  test  set  required  for  certifying  that  systems  have  low  failure  frequen¬ 
cies,  which  makes  manual  examination  of  test  results  impractical.  To  apply  these  tech¬ 
niques  in  practice,  we  need  automated  methods  for  deciding  whether  or  not  the  outputs 
produced  by  a  test  case  conform  to  a  specification. 

An  aspect  of  code  analysis  of  great  practical  importance  is  error  location.  One 
approach  to  this  problem  is  to  derive  weakest  preconditions  for  suspected  pieces  of 
code,  to  characterize  the  space  of  inputs  for  which  the  code  fails.  This  and  other 
approaches  should  be  refined  and  evaluated  to  determine  their  practical  utility. 

3.5.  Evolution  Aspects 

Software  maintenance  is  acknowledged  to  be  more  difficult  and  error  prone  than 
the  initial  development.  An  important  kind  of  software  analysis  for  this  pan  of 
software  development  is  characterization  of  the  effects  of  a  change  to  a  .software  sys¬ 
tem.  Symbolic  representations  for  the  parts  of  the  input  space  and  the  output  space  of 
a  program  affected  by  a  given  change  to  the  code  are  useful  for  testing  and  evaluating 
a  modification  for  conformance  with  the  expected  resulus.  Computer-aided 
identification  of  the  parts  of  a  specification  affected  by  a  given  requirements  change, 
the  parts  of  a  design  affected  by  a  given  specification  change,  and  the  parts  of  the  code 
affected  by  a  given  design  change  are  also  important  areas  for  research. 

When  changing  a  software  system,  it  is  often  necessary  to  reverse  an  earlier 
design  decision  while  preserving  the  later  ones,  and  to  combine  the  effects  of  several 
changes  that  were  developed  independently.  Both  of  these  problems  can  be  addressed 
by  change-merging  techniques  [3]  Automated  construction  and  application  of  mono¬ 
tonic  transformations  that  can  modify  specifications  and  programs  in  respon.se  to  prob¬ 
lems  with  the  current  behavior  of  a  system  is  also  an  important  research  problem. 

4.  Conclusion 

Advances  in  software  analysis,  synthesis  and  certification  are  essential  for  realiz¬ 
ing  trusted  software  systems.  Work  in  this  area  should  be  expanded  beyond  the  tradi¬ 
tional  domains  of  testing  code  in  a  programming  language  and  proving  that  programs 
satisfy  formal  specifications,  to  include  software  products  at  al'  ’ages  of  development 
from  requirements  analysis  to  system  evolution.  Some  key  areas  for  future  research 
are 
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(1)  Methods  for  validating  requirements  and  specifications,  such  as  prototyping  and 
techniques  for  testing  prototypes  and  specifications  relative  to  user  perceptions, 

(2)  Methods  for  constructing  programs  that  guarantee  correctness  with  respect  to  for¬ 
mal  specifications,  such  as  program  synthesis  by  meaning-preserving  transforma¬ 
tions  and  certification  of  application-specific  program  generation  schemes. 

(3)  Approaches  for  making  formal  methods  easier  to  use,  reducing  the  amount  of 
manual  effort  required,  and  for  reducing  the  amount  of  training  and  mathematical 
skill  required  for  practitioners  to  apply  these  methods  by  designing  software  tools 
that  hide  theoretical  complexities  and  provide  simple  interfaces. 

(4)  Methods  relevant  to  software  evolution,  such  as  change  merging,  monc.jnic 
transformations  for  modifying  specifications  and  programs,  and  incremental  ver¬ 
sions  of  conventional  .software  analysis,  synthe.sis,  and  certification  methods. 

(5)  Software  analysis  techniques  addressing  properties  of  parallel,  distributed,  real¬ 
time,  and  knowledge-based  systems  should  be  explored  as  well  as  those  for 
sequential  systems. 

(6)  Further  work  on  program  testing  is  needed.  It  expand  the  domains  in  which  firm 
conclusions  about  satisfying  specifications  can  be  drawn  from  finite  sets  of  test 
cases  constructed  hy  definite  and  effective  methods,  and  to  sy.stematica11y  check 
assumptions  about  the  operating  environment  on  which  the  design  of  a  software 
system  depends. 
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